This application relates to on-line communications. In particular, it relates to a device, system and method for improving a user's experience during on-line communications
Secure on-line communications rely upon the exchange and validation of security certificates. Checking the status of a security certificate, particularly in a mobile or other bandwidth-limited environment, can be sufficiently time consuming as to disrupt a user's experience while obtaining on-line content. In some instances, delays in validating certificates can cause a connection with an on-line content server to timeout, requiring a user to re-initiate the connection.
In general, in order to conduct on-line communications in a secure manner, an agreed set of protocols must be established for the sender and receiver to follow to maintain a secure connection across a network. Currently a common mechanism used on-line is the Transport Layer Security (TLS) Protocol. This protocol is well understood to skilled persons, and is continually updated as a generally available standard. The TLS Protocol is generally described in the “Internet Official Protocol Standards” and updated from time to time (see RFC 5246—standard for TLS version 1.2). Prior to the adoption of TLS, the Secure Sockets Layer (SSL) protocol was widely used.
This application is described with reference to the current protocol generally in use, TLS, though it will be understood that the methods may be applicable for other protocols for exchanging security certificates to authenticate an on-line content provider, and the specific sequence of steps to carry out the handshaking may vary in other protocols.
The TLS protocol provides a mechanism for a client to contact a server across a network in a secure manner. By following the protocol the client and server may establish endpoint authentication of the client and server and an encrypted communication channel between the client and the server. In a typical HTTP application the client contacts the server and requests the server to authenticate itself, while the client may remain anonymous. TLS does more generally support authentication of both parties, which requires each party to have its own security certificate. Most often such bi-lateral authentication is reserved for enterprise applications.
In the example of a TLS protocol, a “handshake” protocol is specified. The handshaking between the client and the server when first starting to communicate establishes: i) an agreed protocol version; ii) selection of a common cryptographic algorithm; iii) optionally authentication of one or both parties; and, iv) exchange of public key encryption information to generate shared secrets (private keys). Typically, most secure communication protocols would generally include these four items.
The TLS Handshake Protocol involves the following steps for bi-lateral authentication (referenced from RFC 5246):                Exchange hello messages between client and server to: agree on algorithms; exchange random values; and, check for session resumption.        Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.        Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.        Generate a master secret from the premaster secret and exchanged random values.        Provide security parameters to the record layer.        Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.        
Once the Handshake Protocol has been completed, the client and server can securely exchange information using the calculated security parameters.
In a typical on-line web environment, however, a client device will conduct a unilateral authentication of an on-line resource. That is, the handshake will authenticate the server by its certificate, but the device is not authenticated by a certificate.
For example, a user attempting to access a secure on-line resource will carry out the TLS handshake protocol, except that the server does not authenticate the client. The client authenticates the server and exchanges the information required to calculate the security parameters to establish a secure connection to the server. This may include, for instance, the following steps:                Client sends the server a “ClientHello” message including TLS, compression and encryption information        Server responds to the client with a “ServerHello” message including TLS, compression and encryption information        Server sends its Certificate message to the Client        Server sends a “ServerHelloDone” message to the Client        Client authenticates Certificate        Client sends the server a “ClientKeyExchange” message        Client and Server use the exchanged information to establish the security parameters        Client sends the Server a “ChangeCipherSpec” to establish connection has been authenticated and future communications will be secured by encryption        Client sends the Server an encrypted “Finished” message        Server decrypts “Finished” message to confirm the handshake and the secure connection from the client's end        Server sends the Client a “ChangeCipherSpec” and a “Finished” message        Client decrypts the “Finished” message to confirm the handshake from the server's end        Handshake complete, secure connection established        
Once connected, the client device will download content from the server, such as html code, java script, etc. . . . , for execution by the client device to present an authentication portal to a user of the client device. The user may then interact with one or more user interfaces resident on the client device to enter authentication information which is sent by the client device to the server over the secure connection. The server may then authenticate the user by authenticating the user-supplied authentication information with server-resident authentication information.
The authentication may comprise a comparison of the received values to server-resident values, or may comprise processing or converting the received values, for instance by using a hash function, before comparing the processed received values with the server-resident values. Other known methods of authentication may also be employed.
One problem faced with on-line authentication, especially in a bandwidth constrained or mobile application, is the latency inherent in authenticating certificates. For mobile client devices, for instance, establishing a TLS connection may be challenged as the time required to carry out the steps necessary to verify the certificate(s) may be too long causing the TLS handshake with the server to time out.
It would be advantageous for a device, system or method to alleviate some of the current problems relating to on-line communications.